PASI tries to minimize the number of errors that stop the normal execution of a service but there are scenarios where PASI cannot continue normal execution. These scenarios include:

• Data Contract exceptions - if the wrong data types are supplied, not providing required values or values exceeding the maximum field length then PASI will return with an exception
• Security exceptions - using an invalid or unregistered client certificate, accessing a service that the client isn't authorized to use or using a deactivated account the PASI core will return an exception
• Unexpected exceptions - if PASI encounters an unexpected error the error is logged and the PASI client is immediately notified.

In the above scenarios the normal service contract is not returned. Instead a fault is returned which includes a fault code and fault string.

The following exception codes can be returned from any service operation (these exceptions will not be duplicated in each service exception list). All validation rules are described in detail in the PASI Validation Rules document.

¹Applies specifically when submitting data. ²Applies specifically to services that take in a PASI Core version.

Note: One way PASI core protects against denial of service attacks by limiting incoming message sizes and uses quotas to restrict memory consumption. The maximum size of a request sent to PASI core can be 65536 bytes (64K). Exceeding this limit will result in a CommunicationException. This type of exception does not return an error code

Example: If an incoming request with thousands of school authority codes is made and if this incoming requests message size exceeds the quota set on PASI, you will receive this exception. You will have to either reduce the number of school authority codes you are requesting on this call or split your request over multiple calls.

Core Alerts are normally less severe than Exceptions. They indicate business rule or rules (i.e. a school must be 'Active' before it can accept enrolments) have been violated but PASI is still able to save the data.

There are four types of Core Alerts:

• Error - Represents a fundamental problem with the record that didn't exist when the record was submitted. This could occur when related data in the PASI core has changed that triggered the error state (i.e. a school calendar year was removed making an existing enrolment invalid). This alert type will be rare but is possible from a system perspective.
• Warning - the data was saved but requires attention. PASI will maintain this core alert until the data has been corrected (i.e. an has an invalid postal code: T6L555).
• Advice - the data was saved but may require attention (i.e. based on previous enrolments the student has appeared to have skipped a grade. This may have been intentional). This alert can be acknowledged so the PASI core is notified that the issue has been looked at. This is done by calling the SubmitEnrolmentStatusAcknowledgement or SubmitStudentStatusAcknowledgement service). Once acknowledged the advice still exists but the corresponding acknowledgement can be used to determine if the user needs to be informed of the advice.

A list of core alerts (if required) is returned on the response of the GetStudentStatus and GetStudentSchoolEnrolmentStatus services for a particular Student or StudentSchoolEnrolment.

When submitting data to the PASI core the service will return a data contract like the following.

With this response the PASI client can immediately see any reasons for a submission being rejected.

Student and registration data can be updated by a number of PASI clients. Some of these changes could potentially affect a change submitted by your PASI client.

For example: On September 1^st you submit an enrolment for student A with your school in grade 10. On September 15^th another school submits an enrolment for student A in grade 11 with the same State Province Id. In this scenario there is potentially an issue with both enrolments since the grades don't match.

PASI core introduces the concept of synchronizing the status of a student and enrolments. Assuming both schools' PASI clients are using data synchronization (see Data Synchronization document) both schools would have received this core alert by calling the IsDataAvailable and GetStudentSchoolEnrolmentStatus services. This would alert both schools (with an advice core alert) to the issue so they can work to resolving the potential issue.

Using the same example, assuming the student was meant to be in grade 11, the services that would be used have been highlighted (in bold):

1. School 1 submits Student A in grade 10(using SubmitStudentSchoolEnrolment).
2. School 1 with IsDataAvailable running in the background GetStudentSchoolEnrolmentStatus is called and the enrolment status has no alerts.
3. School 2 submits Student A in grade 11 with the same State Province Id (using SubmitStudentSchoolEnrolment).
4. School 1 and School 2 using the IsDataAvailable service and receives a Core Alert for the Student A enrolment (through GetStudentSchoolEnrolementStatus).
5. School 1 & School 2 communicate over the phone and realize Student A should be in grade 11.
6. School 1 submits an update Student A's enrolment using SubmitStudentSchoolEnrolment
7. School 1 & School 2 using IsDataAvailable both receive updates indicating that the status of their enrolment has changed and call GetStudentSchoolEnrolmentStatus to retrieve the updated (both containing no alerts)

The following table shows the process again and the timing of the services calls from the prespective of both school (this assumes the IsDataAvailable method is being called repeatedly with a wait time of 1 minute or more).